Object and Schema Versioning and Restructuring in Databases 1

Evolution of persistent data is a critical need for a large class of software systems, like CASE or CAD environments. So, it is quite natural for data management needs to change and for possible drawbacks in the logical database design to be highlighted. In order to satisfy these needs, the data schema must be able to change and the database must be restructured to meet the newly adopted schema. At the same time, existing application programs may also need to be modified to meet the new database structure. In some areas, like engineering of databases or engineering of software, the long-term design process increases the need for schema changes and schema versioning. For these reasons, support for full schema evolution is a required facility in any Database Management System (DBMS). Full schema evolution concerns schema changes, existing data and programs adaptation to the changes and schema versioning. In this paper, we deal with the impact of schema changes on persistent data and on application programs that manipulate these data. We consider both “local” schema changes, like attribute deletion or domain modification, and more complex changes, like schema integration [12, 6]. Three strategies may be followed to manage the side effects of schema change on existing data and programs. The first one, called immediate migration consists in converting all affected data instances eagerly after any schema change. The second strategy called deferred migration [8] delays the data conversion till the end of all the active transactions. These two strategies are both inappropriate for some fields, like software engineering or CAD/CAM, where transactions may be long-term transactions [9]. The third strategy, called opportunistic migration allows the use of a database through more than one schema version. Instances of data are progressively made conform to the modified schema. It means that only newly activated transactions are sensitive to the schema changes. From this quick analysis of migration strategies, it comes that at least two versions of a data schema are needed : a version of the schema before modification and a version after modification. In the immediate or the deferred migration strategies, the “schema before” does not persist after the migration process while it does in the opportunistic strategy. Our investigations do not favour any strategy. We attempt to identify and to define as formally as possible mapping functions from the data schema before being modified into the data schema after the change performance. Mapping functions are defined as schema homomorphisms with a fixed static semantics. Different procedural interpretations of these functions can be provided to enable their use in any migration strategy. Indeed, the same kind of concepts and mechanisms are needed to adapt existing data, and sometimes existing application programs, to schema changes. The approach that is described hereafter is based on the identification and the management of relationships between versions of a schema. These relationships are used to convert data or to adapt programs by rewriting them or using ad-hoc polymorphism[7]. We discuss the procedural issues of our approach including multi-faceted representations of data item and adhoc polymorphism with type coercion to propagate the side effects of a change in a data schema